home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄22⁄91 / 2995-MacApp and C++-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.1 KB  |  62 lines  |  [TEXT/GEOL]

  1. Item    7806927                         18-Feb-91        04:59PST
  2.  
  3. From:   SPA0137                         Objectsoft SA, Spain,IDV
  4.  
  5. To:     S.FRIEDRICH                     Friedrich, Steve
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    MacApp and C++
  11.  
  12. Dear MacApp.Tech$ers,
  13.  
  14. I am responding to a weeks worth of MacApp.Tech$ that I just read. If I don't
  15. mention you by name, you're free to feel singled out anyway.
  16.  
  17. Steve Friedrich and the MacApp team, despite all of the benefits of MacApp, it
  18. has not really been a stable platform on which to develop. Simply recall the
  19. conversion from 1.1 to 2.0 which some out there are still doing. Or remember
  20. the number of bugs in the so-called 2.0 final release. Now a conversion to C++
  21. does not strike me as a step towards stability. Witness the volume of links
  22. complaining of bugs in CFront. The new architecture sounds fantastic, but why
  23. the language change? And why a change to another impure object-oriented
  24. language? Can we expect another 200-300 global variables, and functions in
  25. MacApp 3.0?
  26.  
  27. OK, So Apple system software is written using C++. Do you just want to jump on
  28. the bandwagon, or are you saying that MacApp is system software? I personally
  29. don't see the future of object oriented languages as being anything like C++.
  30. While it may be a suitable tool for writing some system software, is it really
  31. the language for an application program? When people said MacApp was on the
  32. forefront it was in large part because it was written in Object Pascal. Now
  33. Object Pascal may not be a hip language these days, but C++? How about an
  34. Eiffel compiler instead? And if you're making a marketing decision, based on
  35. the popularity of C++, why don't you go to work with MS-DOS computers where
  36. most of the market is?
  37.  
  38. Furthermore, if anyone's planning to make MacApp system software and restrict
  39. the source code, forget it. I haven't used ANY application class library which
  40. didn't provide source code. And I have used a few. Software ICs may be
  41. possible, but I haven't seen a class library yet where you didn't need to
  42. browse the code. And don't mention tools that show me all the relationships.
  43. The relationships that I want to know are what methods, to whom and when, but
  44. not at runtime. I want to browse them in any order. And sometimes I want to see
  45. the code in between, too.
  46.  
  47. Finally, what about future architectural changes? Can I assume that MacApp will
  48. start taking advantage of C++ features? What's really going to happen to the
  49. code? It seems to me, browsing my MacApp 2.0.1 code, that there is quite a bit
  50. that could be cleaned up without a new language to do it in. In fact, the
  51. current MacApp goes a long way towards making Object Pascal unreadable. As far
  52. as maintaining two versions goes, forget it. You guys have enough trouble
  53. maintaining one version.
  54.  
  55. Despite these ravings I will probably continue to use MacApp for Macintosh
  56. software projects. But I will be keeping a look out for other options. Common
  57. Lisp is beginning to look attractive.
  58.  
  59. Barry Wilson
  60.  
  61.  
  62.